Use trampolines for all libcalls in engine-universal and engine-dylib #2748
Conversation
|
This is still incomplete: LLVM is bypassing the trampoline generation since it generates the object file directly. |
Amanieu
force-pushed
the
libcall_trampolines
branch
from
68f1f69
to
e04ea30
Compare
|
I think @ptitSeb will be the best one to review this |
Amanieu
force-pushed
the
libcall_trampolines
branch
from
35af8a7
to
1611792
Compare
|
Blocked on gimli-rs/object#422. |
Amanieu
force-pushed
the
libcall_trampolines
branch
2 times, most recently
from
1be3c73
to
6e40e90
Compare
|
Ready for review |
|
This LGTM, @ptitSeb can you take a look to approve it or give feedback? |
| // We currently allocate all code segments independently, so nothing | ||
| // is colocated. | ||
| colocated: false, | ||
| colocated: true, |
There was a problem hiding this comment.
I might be missing some context on what colocated means. Why is this necessary?
There was a problem hiding this comment.
This is necessary to avoid text relocations. It means that all libcalls are reachable through normal call instructions (+/- 2G on x86, +/- 128M on aarch64) so it doesn't need to load the target from memory and do an indirect call. This is true since we generate trampolines that are near the compiled code.
The text relocations are due to the way Cranelift generates indirect calls: it places the target as a pointer in the .text section (since it puts everything in .text) and marks it with a relocation so the linker fills in the libcall address at load time.
In both of these engines, the compiled code may be loaded in memory far from the Wasmer runtime which means that libcalls may not be reachable through the normal relocation types. Instead a trampoline is needed to allow reaching any address in the 64-bit address space. In the case of engine-dylib, this is even worse since the symbols are not exported by the executable without some special linker flags. The solution here is to manually patch in the addresses at load time into a data table of function pointers.
Amanieu
force-pushed
the
libcall_trampolines
branch
from
6e40e90
to
ffb9cd3
Compare
|
bors r+ |
In both of these engines, the compiled code may be loaded in memory far
from the Wasmer runtime which means that libcalls may not be reachable
through the normal relocation types. Instead a trampoline is needed to
allow reaching any address in the 64-bit address space.
In the case of engine-dylib, this is even worse since the symbols are
not exported by the executable without some special linker flags. The
solution here is to manually patch in the addresses at load time into
a data table of function pointers.
Fixes #1722